SQL Server 2008 : Security and Compliance - SQL Server Auditing

An audit is the combination of several elements into a single package for a specific group of server actions or database actions. The components of SQL Server Audit combine to produce an output that is called an audit.

The SQL Server Audit feature in SQL Server 2008 is intended to replace SQL Trace as the preferred auditing solution. SQL Server Audit is meant to provide full auditing capabilities, and only auditing capabilities, unlike SQL Trace, which also serves for performance debugging. The SQL Server Audit feature is built on top of Extended Events, a new high-performance eventing infrastructure introduced in SQL Server 2008. SQL Server Audit leverages the performance benefits of Extended Events, which provides both asynchronous and synchronous write capabilities (by default, SQL Server Audit uses the asynchronous eventing model).

SQL Server Audit is also tightly integrated with the Windows operating systems and can push (write) its audits to the Windows Application or Security Event Log. With SQL Server Auditing, you can set up auditing of just about any event or execution within SQL Server, and it can be as granular as you need (right down to a table and operation level). This capability is important because not only can you track all these events, but you can use this auditing capability to fulfill application and database audit compliance and look for patterns of misuse, or even specific “hot” objects that contain the most sensitive data in your database.

As you can see in Figure 1, a branch under each database called Security contains several of the common security-related nodes that you’ve seen before (Users, Roles, Schemas, and so on). But now, there is a Database Audit Specifications branch from which you can set up and view the database audit specifications you have defined. You can have as many specifications as you want, and again, they can be at varying levels of granularity.

Before you can set up a Database Audit Specification, however, you must first set up a SQL Server Audit object. To do this, you must use a couple of new entries in the Object Explorer under the Security folder at the SQL Server instance level: Audits and Server Audit Specifications.

Essentially, three main objects describe audits in SQL Server 2008:

• The Server Audit object— Used to describe the target for audit data, plus some top-level configuration settings. This destination can be a file, the Windows Application log, or the Windows Security log. The Server Audit object contains no information about what is being audited—just where the audit data is going. Multiple Server Audit objects can be defined with each object independent from one another (that is, they can each specify a different destination).

• The Server Audit Specification object— Used to describe what to audit at a server instance-wide level. A server audit specification must be associated with a Server Audit object to define where the audit data is written. There is a one-to-one relationship between the Server Audit Specification object and the Server Audit object.

• The Database Audit Specification— Used to describe what to audit at a specific database level. Where the audit data is written is determined by the Server Audit object it is associated with. Each database audit specification can be associated with only one server audit. A server audit can be associated with audit specifications for multiple databases, but only one database audit specification per database.

To create a new Server Audit object, right-click on the Audits item in Object Explorer and select New Audit (see Figure 2).

Figure 2. Creating a new Server Audit object in Object Explorer at the Server instance level.

When you set up a Server Audit object, you specify where the audit information will be written to. In Figure 3, you can see that we are creating a server audit named NEW_SQL_Server_Audit and are defining it to use the Application log at the Windows operating system level as the audit destination. You can also choose to write to the Windows Security log or to a text file. Events written to the Application or Security Event log can be accessed with Event Viewer or with specialized Event log management software, such as Microsoft Systems Center Operations Manager.

Figure 3. The Create Audit dialog.

After you set up the Server Audit object, the next step is to go to the Database Audit Specifications folder, as shown in Figure 1, in the database for which you want to set up auditing. Right-click this folder and select New Database Audit Specification to bring up the dialog shown in Figure 4. This is where you define your database-level audits.

Figure 4. The Create Database Audit Specification dialog.

In the Create Database Audit Specification dialog, you specify the name of the Database Audit object and the Server Audit object it will be running under. In this example, the Database Audit name is NEW_Database_Audit_Specification, and it will be running under the NEW_SQL_Server_Audit Audit object defined in Figure 13.9. In this example, the database audit is being set up to audit any SELECT statements (reads) run against the Employee table (which, of course, contains company-sensitive employee data) by any user (public).

At this point you have created a Server Audit object and database audit specification associated with the server audit. However, neither of these audits is enabled. You can enable them by right-clicking on each and selecting Enable. As soon as the Server Audit object is enabled, it begins auditing and writing audit records to the specified destination (in this example, the Windows Application log).

Cannot alter a server audit from a user database. This operation must be
 performed in the master database.

Figure 5. Log File Viewer showing the audit events of a SQL Server Audit object.

Within the Log File Viewer, you can filter your audit results or search them to look for patterns, specific violations, and so on. From the Log File Viewer, you also have the option of exporting the audit logs to a text file or to a comma-separated values (CSV) file. With a CSV file, you could import the audit logs into a database for further analysis and correlation. It’s up to your security and audit team to decide how these audits are to be used.

In addition to database-level auditing of actions at the database level, you can also set up auditing of server-level events, such as management changes and logon and logoff operations. These are set up in the SSMS Object Explorer through the Server Audit Specifications item in the Security folder for the SQL Server instance.